Transmission of media content (e.g., video, audio, and/or data, etc., collectively or individually referred to herein also as content) between different nodes on a network may be performed in a variety of ways. The type of content that is the subject of the transfer and the underlying network conditions usually determine the methods used for communication. For instance, for a simple file transfer over a lossy network, one emphasis is on reliable delivery. The packets may be protected against losses with added redundancy or the lost packets may be recovered by retransmissions. In the case of audio/video content delivery with real-time viewing requirements, one emphasis is on low latency and efficient transmission to enable the best possible viewing experience, where occasional losses may be tolerated.
The structure of the packets and the algorithms used for real-time media transmission on a given network may collectively define a chosen media streaming protocol. Although various media streaming protocols available today differ in implementation details, they can generally be classified into two main categories: push-based protocols and pull-based protocols. In push-based streaming protocols, once a connection is established between a server (e.g., server device or server software) and a client (e.g., client device or client software), the server remains active on the session and streams packets to the client until the session is torn down or interrupted. In pull-based streaming protocols, the client is the active entity that requests the content from the server. Thus, the server response depends on the client request, where otherwise the server is idle or blocked for that client. Further, the bitrate at which the client receives the content is dependent upon the client capabilities and the available network bandwidth. As the primary download protocol of the Internet, HTTP is a common communication protocol upon which pull-based media delivery is based.
In pull-based adaptive streaming, the client makes a decision about which specific representation of any given content should be requested next from a source. Such a decision may be based on various parameters and/or observations, including the current (observed/available) bandwidth and the amount of data in a client buffer. The client may up-shift or down-shift (e.g., switch to a higher or lower bitrate) or stay at the same bitrate to provide a continuous playout at the highest quality possible. The bitrate switching decision may be revised periodically, and then a new chunk at the determined profile is requested. For instance, if the client experiences a reduction in the streaming rate, the client may decide to down-shift. However, if lower quality content is not available nearby (e.g., on a cache server), this request may result in an upstream cache fill, where the cache server requests the missing content from an upstream server. If the original congestion is in the upstream network, this down-shift process may cause performance issues.